A common form of communications between computers connected to the Internet follows a paradigm known in the industry as client-server. For example, existing servers are email servers, web servers, file servers, online banking servers, etc. Clients include home personal computers, office personal computers, laptop computers, hand-held devices, wireless digital telephones, etc. The various client devices connect and interact with the various server devices. In this model the different servers employ their own ways of authenticating and authorizing the client devices that connect with them. For example, some email servers issue and use pre-registered identities to authenticate and authorize. Some banking organizations use their own member identification and password databases to do the authentication and authorization. So a given client device, say a personal computer at home, needs to conform to the differing authentication methods enforced by the different servers with which it connects and interacts. In the client-server model, the broad problem of how two interacting computers “recognize” one another currently is solved by making the server computer enforce its preferences unilaterally on the client computer.
Although the above-described model works well for client-server interaction, it becomes impractical for interactions between the various client machines themselves. The industry terminology for such interaction between various client devices is called peer-to-peer (P2P) communications. In this case, neither client computer can force its authentication preferences on the other. For example, consider the desire for a first user, Alice, to share and exchange videos and pictures from her personal computer with a second user, Bob, who also has a personal computer. Bob may wish to authenticate Alice, in order to be confident that the videos and pictures are indeed being sent by her, rather than being sent by an imposter.
Additionally, Alice may wish to transmit the videos and pictures securely using an encryption technique such as RSA, so that an eavesdropper cannot view the videos or pictures. RSA is a public-key cryptography technique whereby anyone can encrypt data for a given user with the user's public-key, but only the user can decrypt the data by using the corresponding private-key. Thus, Alice and Bob need to first exchange their respective public-keys in order to establish the secure channel per the RSA algorithm. Exchanging public-keys is not a trivial task. Charlie, a malicious hacker, could try to “sit in the middle” of the key exchange communication. Charlie sends his own public-key to Alice, but pretending to be Bob; he sends his own public-key to Bob, but pretending to be Alice. Given that this initial key exchange communication is itself not secure, there is no simple way for Alice and Bob to realize that Charlie is “in the middle”. If they fall for Charlie's ploy and start communicating using his key, he can act as the middle-man and pass all the communications between Alice and Bob, but be able to eavesdrop on all the content being passed back and forth. And of course he can make this even worse by changing the passed content as well.
Thus, Alice and Bob have a problem of how they can confidently “bootstrap” the exchange of public keys onto their communications session. More generally, the bootstrapping problem in a P2P setting involves exchanging any sort of public data or digital object such that the recipient is confident it came from the purported sender.